Not Applicable.
Not Applicable.
The present invention relates generally to communication networks and, more particularly, to communication networks having servers for servicing traffic sources.
Telecommunication networks having various switches and routers for making connections over the network are well known in the art. As is also known, a centralized database or application server can form a part of many communication networks. For example, in the ATandT Public Switched Network, a database system known as Segmentation Directory (SD) is used to process a query for successful completion of practically every call received in the network. Other instances of centralized servers include Network Control Points (NCPs) for providing various call setup and processing tasks, such as number translation, routing, authentication, billing and security. In Internet Protocol (IP) networks, centralized servers are essential parts of many Web services. Because of their role in providing service, it is often imperative that these servers function at their rated capacity at all times.
In general, a server receives queries or service requests from several Traffic Sources (TS). After successfully processing a query, the server sends a response back to the TS. When a server receives more queries than its capacity in a given time period, its throughput drops and it is said to be in overload. The term overload can also be used loosely to describe a query load above an allowed level. This is the case, for example, for Dialed Number (DN) controls. Each number is assigned an allowed traffic level. When that level is exceeded, the DN is said to be in overload, and an overload control may be used to block some queries at the traffic sources.
There are several known strategies that are used to mitigate the effect of overloads. Duplicate server sites may be used for redundancy or load distribution. Excess queries may be discarded after they reach the server. However, this control strategy uses valuable server resources, and is generally used as the control of last resort, since server throughput and response time drop under overload. Most traffic sources have a timeout mechanism in which, after a fixed period, a query with no response is either resent to the server, or to another server, or is abandoned. Under server overload, the server throughput drops and the query response time is also delayed, resulting in time-outs, retrials, or abandonment of queries at the traffic source. Overload and subsequent retries at some traffic sources can cause the overload to feed on itself and spread to other traffic sources.
Another known control technique attempts to limit excess queries from reaching the server. Such preemptive control protocols have been developed in which an overloaded server requests the traffic source to restrict the query load sent to the server. A traffic source can restrict the number of queries sent to the server using a control mechanism. The control mechanism at the traffic source can have several discrete control levels that can be applied to restrict the traffic going to the server at different rates. In response mode, the server xe2x80x9crespondsxe2x80x9d with a control message to the source of every query that is processed successfully by the server. The number of control messages in this mode is acceptable if the server throughput is moderate, but can rise substantially if the server capacity is high, causing a drop in server throughput and congestion in the signaling network. For servers with large throughput, the broadcast mode is preferred. In broadcast mode, the overloaded server xe2x80x9cbroadcastsxe2x80x9d control messages to all traffic sources at a specified control interval. The effectiveness of controls in the response mode depends on the number of traffic sources. The larger the number of traffic sources, the longer it takes to control an overload since each source needs to send at least one query to the server in order to receive a control message. However, broadcast mode is effective almost immediately at all traffic sources with one broadcast.
In a further known control strategy, the control mechanism at the traffic source may be customized, as in case of several controls used in ATandT""s networks, or may follow industry standards so that the control may work with traffic sources from several different vendors that follow the standard. Standard protocols allow flexibility in network operation and growth and permit interoperability with other network providers. However, standard protocols are designed to serve generic needs and may not offer the best solution for a specific application. For instance, only a limited number of control levels may be defined in the standards. This limitation can compromise the effectiveness of the control for specific applications. For example the server throughput may oscillate and may remain substantially below its rated capacity if only the standard control levels are used.
It would, therefore, be desirable to overcome the aforesaid and other disadvantages of known overload control mechanisms.
The present invention provides a network traffic overload control mechanism that utilizes space chattering to maximize server throughput under overload conditions generated by various classes of traffic sources. With this arrangement, network servers can provide throughput at or near rated capacity during overload by controlling loads from a plurality of traffic sources, which can have different control schemes. While the invention is primarily shown and described in conjunction with a network having servers for handling service requests, it is understood that the invention is applicable to networks in general in which it is desirable to service clients as efficiently as possible.
In one aspect of the invention, a method of controlling overload includes determining a traffic level generated by first and second classes of traffic sources and determining whether the traffic level is within a predetermined range. If the traffic is outside the range, a base control vector, which includes base control values for the classes of traffic sources, is computed from an ideal control driver, which would bring the traffic level within range. For each class, the base control value typically falls between two consecutive discrete control levels for the traffic sources. A chattering vector is then computed from the base control vector and the desired traffic level. For each class, the first and second subsets of the first class of traffic sources are derived based on the chattering vector. The first subset receives a first or low control and the second subset receives a second or high control, wherein the first and second controls correspond to discrete control levels for the class of traffic source.